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1.0  Introduction 

The  Global  Ocean  Forecast  System  (GOFS)  Version  2.6  (V2.6)  combines  the  global 
coverage  and  relatively  high  vertical  resolution  of  the  Navy  Coastal  Ocean  Model 
(NCOM),  along  with  the  Navy  Layered  Ocean  Model  (NLOM;  Shriver  et  ah,  2007),  the 
Modular  Ocean  Data  Assimilation  System  (MODAS;  Fox  et  ah,  2002),  and  in  situ  profile 
data  assimilation  via  the  Navy  Coupled  Ocean  Data  Assimilation  (NCODA;  Cummings, 
2005)  system  to  best  represent  the  evolution  of  deep  water  fronts  and  eddies.  The  GOFS  is 
commonly  referred  to  as  “global  NCOM”  within  the  operational  community,  given  that 
the  widely  used  global  NCOM  boundary  conditions  launch  several  other  systems  in  the 
daily  operational  runstream.  GOFS  provides  enhanced  skill  in  the  nowcasting  and 
forecasting  of  global  ocean  environmental  conditions,  including  surface  and,  where 
applicable,  three-dimensional  (3D)  predictions  of: 

•  Temperature 

•  Salinity 

•  Surface  elevation 

•  Ocean  velocity  (current  speed/direction  or  velocity  components) 

•  Volume  transport 

•  Eddy  kinetic  energy 

•  Sound  speed 

•  Additional  derived  ocean  properties 

1.1  NLOM  in  GOFS 

Global  NLOM  has  coarse  vertical  resolution  and  excludes  the  Arctic  Ocean  and  regions 
shallower  than  200m.  However,  its  horizontal  resolution  is  very  high  at  1/32°,  giving  it 
excellent  skill  in  representing  deep  water  fronts  and  eddy  locations.  The  sacrifices  in 
vertical  resolution  and  area  coverage  enable  NLOM  to  be  operational  at  very  high 
resolutions.  NLOM  directly  assimilates  track-by-track  altimeter  data  and  MODAS  2D  sea 
surface  temperature  (SST)  analyses.  The  1/32°  NLOM  was  used  exclusively  in  the  GOFS 
V2.6  beginning  in  the  fall  of  2005  and  was  declared  operational  in  March  2006.  Shriver 
et  al.,  (2007)  discussed  the  analyses  performed  to  declare  the  1/32°  NLOM  superior  to  the 
1/16°  NLOM  and  Barron  et  al.,  (2007)  compared  differing  versions  of  NLOM  in  a  GOFS. 

1.2  NOGAPS  in  GOFS 

GOFS  V2.6  uses  atmospheric  forcing  from  the  Navy  Operational  Global  Atmospheric 
Prediction  System  (NOGAPS).  The  0.5°  version  of  NOGAPS  has  been  the  atmospheric 
component  since  January  2005.  Atmospheric  forcing  files  are  created  using  time  varying 
u  and  v  component  surface  wind  stresses,  air  temperature,  air  mixing  ratio,  and  net  solar 
radiation.  NOGAPS  contributes  these  parameters,  where  available,  as  this  is  important  for 
the  ocean  mixed  layer  where  inertial  oscillations  are  excited  by  transient  forcing  from 
surface  winds  (Rosmond  et  al.,  2002).  Operational  runs  use  three-hourly  forcing.  Sensible 
and  latent  heat  fluxes  are  strongly  dependent  on  SST,  so  these  are  calculated  every  time 
step  using  the  model  SST  in  bulk  formulations  that  include  the  effects  of  air-sea  stability 

Manuscript  approved  October  13,  2009. 


1 


NRL/MR/7320- 10-92 10 


GOFS  User’s  Guide  Version  2.6 


through  the  exchange  coefficients  (Kara  et  ah,  2002).  The  annual  climatological  SST 
cycle  is  built  into  the  model  to  a  limited  extent  via  the  atmospheric  air  temperature. 
Including  air  temperature  in  the  fonnulations  for  latent  and  sensible  heat  flux  along  with 
model  SST  in  the  bulk  formulation  automatically  provides  a  physically  realistic  tendency 
towards  the  correct  SST  (Kara  et  al.,  2003b).  Although  radiation  fluxes  also  depend  on 
SST  to  some  extent,  these  fluxes  are  obtained  directly  from  NOGAPS  in  order  to  utilize 
the  atmospheric  cloud  mask. 

1.3  MODAS  in  GOFS 

Global  NCOM  assimilates  temperature  (T)  and  salinity  (S)  fields  generated  by  MODAS. 
MODAS  is  a  global  statistical  model  containing  a  bimonthly  climatology  that  records 
correlations  at  each  location  between  surface  temperature,  surface  steric  height  anomaly, 
and  temperature  deviation  as  a  function  of  depth.  Salinity  is  derived  from  temperature  by 
climatological  correlations  between  T  and  S  and  also  as  a  function  of  depth  (Fox  et  al., 
2002a).  In  GOFS  V2.6,  MODAS  is  used  to  translate  NLOM  sea  surface  height  (SSH)  into 
3D  temperature  and  salinity  fields  suitable  for  assimilation  into  global  NCOM.  The 
altimetry  information  is  introduced  to  NCOM  by  this  transference.  GOFS  takes 
advantage  of  the  relatively  deep  water  skill  and  data  assimilation  of  the  sub-polar  global 
ocean  NLOM  through  MODAS’  statistical  ocean  model.  Temperature  is  taken  from  the 
MODAS  2D  SST  analysis,  and  SSH  anomaly  is  estimated  as  the  deviation  of  baroclinic 
NLOM  SSH  from  its  multi-year  mean.  It  can  then  be  optionally  corrected  for  the 
difference  between  the  mean  MODAS  and  mean  NLOM  SSH.  The  synthetics  use  NLOM 
SSH  only  in  deep  water  within  the  NLOM  domain.  Other  areas  use  synthetic  profiles 
based  solely  on  MODAS  2D  SST. 

1.4  In  situ  Observations 

In  situ  observations  may  also  be  assimilated  into  the  3D  analyses.  Data  assimilation  used 
in  NCOM  is  performed  using  two  mechanisms:  1)  adjustment  of  surface  heat  and  salinity 
fluxes,  and  2)  insertion  of  subsurface  T  and  S  profiles.  In  both  cases,  the  strength  of 
assimilation  is  controlled  by  a  gridded  weighting  function  that  reflects  the  relative 
confidence  between  the  model  and  the  data.  Preparation  of  the  data  fields  is  independent 
of  the  NCOM  assimilation  itself,  allowing  the  model  to  accommodate  many  approaches  to 
preparing  observational  analyses. 

In  the  most  recent  upgrade  to  GOFS  V2.6,  the  mixed  layer  depth  (MLD)  of  the  synthetic 
profiles  is  adjusted  to  that  of  an  input  MLD,  such  as  from  NLOM.  Below  the  new  MLD, 
blending  with  the  original  synthetic  profile  is  accomplished  via  exponential  weighting 
(Barron  et  al.,  2008).  The  resulting  global  3D  fields  comprised  of  the  MLD-modified 
MODAS  synthetic  profiles  are  then  used  as  the  background  or  first  guess  field  for  a 
standalone  NCODA  analysis.  The  3D  T  and  S  fields  that  have  been  updated  with  in  situ 
profile  data  are  then  assimilated  into  GOFS  V2.6  by  depth  and  geographically  dependent 
relaxation  scales. 

1.5  PIPS  in  GOFS 

The  GOFS  V2.6  also  has  been  coupled  to  the  Polar  Ice  Prediction  System  (PIPS)  Version 
3.0,  a  dynamic  sea-ice  model  that  forecasts  conditions  in  all  sea-ice  covered  areas 
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in  the  northern  hemisphere  (down  to  30°  North  in  latitude).  PIPS  has  a  horizontal 
resolution  of  approximately  9  km  and  a  vertical  resolution  of  45  levels  so  that 
Arctic  shelves,  continental  slopes  and  submarine  ridges  are  accurately  represented. 
In  PIPS  3.0,  the  Los  Alamos  Sea  Ice  Model  (CICE)  (Hunke  and  Dukowicz,  1997)  model 
is  coupled  to  NCOM  to  predict  multi-category  ice  thickness,  concentration,  and  drift  in  the 
Arctic  Ocean  (Posey  et  ah,  2008b).  Coupling  is  accomplished  via  exchange  of  regridded 
fields.  CICE  receives  global  NCOM  SST  and  surface  velocities  over  the  CICE  model 
domain.  NCOM  receives  ice  concentration,  SST,  heat  flux  and  ice-ocean  stress  the  day 
following  the  daily  PIPS  run.  These  PIPS  fields  will  replace  climatological  fields  of  SST, 
heat  flux,  and  wind  stress  in  the  Arctic  regions  to  produce  a  more  realistic  representation 
of  the  Arctic. 

GOFS  V2.6  typically  runs  a  three-day  hindcast  and  three-  to-  five  day  forecast  in 
operational  mode.  Atmospheric  forcing  comes  through  winds  and  heat  fluxes  from 
NOGAPS.  A  database  of  almost  1000  rivers  from  around  the  world  feeds  into  the  river 
input  of  GOFS  V2.6  (Barron  and  Smedstad,  2002). 


1.6  Advantages  of  GOFS  V2.6 

GOFS  V2.6  provides  a  resource  allocation  choice  that  combines  multiple  sub-optimal 
models  to  achieve  a  superior  system  to  that  of  any  one  of  its  component  models  run 
individually.  It  is  a  global  mesoscale  ocean  model  extending  from  Antarctica  to  a  full 
Arctic  domain,  including  deep  and  coastal  regions  and  global  river  inflows.  It  also 
assimilates  synthetic  T  and  S  profiles  derived  from  global  SST  analyses  and  SSH  from  a 
higher  horizontal  resolution  deep-water  global  ocean  model  (via  MOD  AS).  The 
following  advantages  exist  from  the  series  of  GOFS  developments: 

•  Full  global  ocean  coverage  within  the  main  model. 

•  Nominal  coverage  of  1/8°  latitude  (about  14  km)  at  45°S. 

•  A  global  curvilinear  horizontal  grid  that  balances  preservation  of  grid  cell  aspect 
ratios  near  1,  efficient  distribution  of  grid  points,  and  maintenance  of  a  logically 
rectangular  grid  with  singularities  sufficiently  removed  from  ocean  portions  of  the 
domain. 

•  Coverage  of  global  coastal  regions  through  inclusion  of  both  deep  and  shallow 
water  to  a  minimum  nominal  depth  of  5  m. 

•  Sigma-z  vertical  coordinate  incorporation  to  allow  for  improved  vertical  resolution 
and  to  avoid  problems  of  sigma  coordinates  over  continental  slopes  and  z- 
coordinates  in  models  over  regions  where  both  deep  and  shallow  areas  must  be 
resolved. 

•  High  vertical  resolution  for  a  global  model,  with  maximum  rest  spacing  of  1  m  for 
the  surface  material  level.  This  will  improve  SST  and  mixed-layer  depth 
capabilities. 

•  Global  coupling  of  a  high  horizontal  resolution  deep  water  model  to  an  accurate, 
deep  and  shallow  water  thermodynamic  model  at  high  vertical  resolution. 
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•  Inclusion  of  fresh  water  inflow  from  the  major  rivers  of  the  world  with 
development  of  a  global  database  of  monthly  river  climatology  (Barron  and 
Smedstad,  2002). 

•  The  ability  to  host  higher-resolution  nested  models. 

•  Optimal  scalability  and  portability  for  efficient  use  of  high-performance 
computing  resources. 

•  Generic  global  regridding  for  scalar  and  vector  quantities  from  the  global  model  to 
arbitrary  output  points,  profiles  or  grids. 


1.7  New  Features 

The  most  observable  improvements  are  in  situ  observations  (via  NCODA  using  the  MLD- 
modified  MODAS  synthetics  as  the  first  guess).  GOFS  V2.6  has  the  following  combined 
value  added  over  existing  global  ocean  modeling  capabilities: 

•  Assimilation  via  relaxation  to  an  analysis  of  observed  T  and  S  and  synthetic 
profiles.  The  synthetics  are  generated  by  MODAS  using  SST  from  MODAS  2D 
and  SSH  from  NLOM.  NLOM  operates  solely  in  subpolar  deep  water  with  coarse 
vertical  resolution,  but  its  higher  horizontal  resolution  makes  it  a  good  dynamic 
interpolator  of  altimetry  data,  as  well  as  an  excellent  predictor  of  front  and  eddy 
location  in  deep  water.  After  modifying  the  synthetic  profile  MLD  using  an  input 
MLD  from  NLOM,  observed  T  and  S  profiles  from  NAVOCEANO  OCNQC  are 
assimilated  via  NCODA  using  the  T  and  S  synthetics  as  the  first  guess 
(Cummings,  2005).  OCNQC  is  an  ocean  data  quality  control  program  that  works 
in  conjunction  with  NCODA  to  perform  automated  quality  control  measures  on  all 
operationally  relevant  ocean  data  streams. 

•  Two-way  coupling  (via  file  transfer)  with  the  Polar  Ice  Prediction  System  (PIPS) 
3.0,  containing  a  sea  ice  model  (CICE)  running  operationally  after  the  global 
NCOM  daily  run  with  an  Arctic  grid  spacing  of  approximately  9  km. 

•  Suitability  for  feedback  into  a  data  analysis  system  using  the  model  forecasts  as  a 
first-guess  field  for  subsequent  analyses. 

•  Compatibility  as  the  ocean  component  of  a  coupled  ocean-atmospheric  model 
prediction  system. 
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2.0  Application 

2.1  Description  of  GOFS  V2.6  Usage 

This  manual  describes  the  procedures  for  running  the  Global  Ocean  Forecast  System 
(GOFS)  Version  2.6.  Because  GOFS  V2.6  delivers  outputs  from  the  global  version  of 
the  NCOM  4.0  model,  all  general  NCOM  operational  instructions  and  details  may  be 
found  in  the  User’s  Manual  for  the  Navy  Coastal  Ocean  Model  (NCOM)  Version  4.0 
(Martin  et  ah,  2008a).  The  user  may  also  refer  to  the  NCOM  Software  Design 
Description  (SDD),  which  describes  the  model  code  (Martin  et  ah,  2008b),  an  article  by 
Barron  et  ah,  (2006),  which  discusses  NCOM  physics  and  basic  equations,  and  two 
Validation  Test  Reports  (Barron  et  ah,  2007a,  2008)  for  additional  insight  into  the  NCOM 
system.  Only  instructions  specific  to  operating  the  model  globally  will  be  discussed  here. 

2.2  Model  Code  Directory  Structure 

The  directory  structure  for  operational  use  of  the  GOFS  V2.6  system  is  identical  to  the 
NCOM  4.0  directory  structure  except  for  the  /misc_global  subdirectory,  found  within  the 
/src  file  folder.  Refer  to  (Martin  et  ah,  2008b)  for  the  complete  model  code  directory 
structure. 

src/- 

misc  global/-  Pre-  and  post-processing  programs  for  GOFS. 

Makefile-  Builds  miscellaneous  programs. 

addndays.F-  Adds  offset  to  DTG. 

daysdiff.F-  Computes  difference  in  days  b/w  two  date 
groups. 

idaysdiff.F-  Computes  diff.  in  integer  days  b/w  two  date 
groups. 

ihrsdiff.F-  Computes  diff.  in  hours  between  two  date 
groups. 

ncom_atm_prep_puvhs.5.F-  Reads  NOGAPS  0.5°  files  and 
uses  pressure,  wind  stresses,  longwave 
components  of  surface  heat  fluxes,  and  solar 
radiation  fields. 

ncom_atm_prep_puvhtms.5.F-  Reads  NOGAPS  0.5°  files 
and  uses  pressure,  wind  stresses,  longwave 
components  of  surface  heat  fluxes,  dewpoint 
depression,  and  air  temperature  fields. 

ncom_atm_prep_uvhtms.5.pf.F-  Reads  NOGAPS  0.5°  files 
and  applies  a  pole  filter  in  the  longwave 
radiation  field  using  wind  stresses,  longwave 
components  of  surface  heat  fluxes,  air 
temperature,  dewpoint  depression,  and  air 
temperature  fields. 

ncom_fixrst.F90  -  Takes  in  restart  file  with  values  outside  of 
limits  and  clamps  to  allowed  values. 
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ncom  sstsss.F-  Gets  SST  and  S  from  binary  files  and  stores 
on  the  GOFS  grid. 

ncomtsnc.F-  Gets  3D  T  and  S  from  binary  files  and  stores 
them  on  the  GOFS  grid. 

extend_dcwinds.F90-  Fills  time  gaps  in  grid  files  for  model 
input. 

extractfrompips.F90-  Writes  a  MODAS-style  netCDF  file 
for  each  extracted  field. 

extractfrompips_f90.F90-  Reads  a  set  of  two-dimensional 
(2D)  and  3D  netCDF  files. 

ncom_atmuvhtms_icemask3.F90-  Reads  2D  atm  forcing  and 
ice  mask  fields  of  the  same  dimension  in 
direct  access  binary  files.  It  replaces  wind 
fluxes  with  ocean  fluxes.  It  uses  PIPS  total 
heat  flux  where  PIPS  output  ice  concentration 
is  >15%. 

ncom_atmuvhtms_icemask3.01.F90-  Performs  the  same 
functions  as  the  above  file,  with  a  PIPS 
output  ice  cone,  of  >1%. 

ncom_nc2atmice.F90-  Reads  2D  and  3D  netCDF  files. 
Writes  in  direct  output  format. 

ncom_out2ncplus.F90-  Converts  direct  access  2D  or  3D 
output  files  to  netCDF  format. 

ncpack2nc.F90-  Converts  compressed  netCDF  to 
uncompressed  for  easier  input  into  packages 
such  as  MATLAB. 


2.3  Memory  and  Processor  Allocation 

In  order  to  successfully  execute  global  1/8°  NCOM,  there  must  be  at  least  50  GB  of  RAM 
distributed  among  the  parallel  processors.  Thus,  256  processors  with  256  MB  each  will 
suffice,  as  will  64  processors  with  1  GB  each.  The  binaries  and  source  code  require  at 
least  30  MB  of  disk  space,  with  a  need  for  at  least  100  GB  of  scratch  space  for  I/O  of 
restart,  forcing,  assimilation,  and  output  files. 

2.4  NCOM  Subversion  Repository 

NCOM  developers  at  NRL  routinely  make  improvements,  changes  and  bug  fixes  to  the 
model,  often  simultaneously.  Therefore,  they  have  created  an  NCOM/GOFS  Subversion 
Repository  (http://subversion.tigris.org/;  Collins-Sussman  et  ah,  2007),  whereby  different 
editions  of  NCOM  and  GOFS  V2.6  are  stored  and  available  for  user  access.  These 
repositories  also  serve  as  backup  in  the  event  of  a  loss  of  operational  system  files.  The 
internet  address  for  the  repository  is  https://www7320.nrl ssc.navy.mil/svn/repos/NCOM 
for  the  NCOM  code  or  https://www7320.nrlssc.navy.mil/svn/repos/GOFS  for  the  system 
scripts  and  MODAS  scripts.  For  web  browser  (read-only)  viewing,  via  WebSVN,  the 
repository  is  available  at  https://www7320.nrlssc.navy.mil/svn/websvn. 
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The  Global  NCOM  code  is  embedded  in  the  trunk  of  the  NCOM  repository.  It  is 
compiled  as  described  in  Section  2.4.1  below,  with  GLOBAL  C  pre-processor  flags 
turning  on  the  necessary  routines  and  array  sizes  for  a  global  model,  including  an  Arctic 
domain. 

The  repository  is  accessible  to  Naval  Research  Laboratory-  Stennis  Space  Center  (NRL- 
SSC)  personnel  as  well  as  to  select  Department  of  Defense  (DoD)  internet  protocol  (IP) 
addresses  outside  the  NRL-SSC  system,  such  as  the  High  Performance  Computing 
Modernization  Program’s  (HPCMP)  DoD  Supercomputing  Resource  Center  (DSRC) 
platforms.  A  user  account  must  be  requested  from  and  created  by  Tim  Campbell 
(tim.campbell@nrlssc.navy.mil).  Send  Dr.  Campbell  a  digitally  signed  email  request  and 
he  will  reply  with  an  encrypted  email  containing  a  username  and  initial  password.  After 
receiving  the  initial  password,  go  to  https://www7320.nrlssc.navy.mil/svn/websvn  and 
click  on  the  "Change  Your  SVN  Password"  link  to  change  the  password. 

2.4.1  Global  NCOM  Build  Information 

README.make  contains  essential  GOFS  V2.6  build  information.  GNUmake  is  required 
for  the  GOFS  build.  Note  that  on  some  platforms  GNUmake  is  referred  to  as  “gmake”. 
Compiling  for  a  global  simulation  requires  the  following  commands: 

setenv  NCOM  ARCH  "ibm  sp" 
setenv  NCOM  COMP  "default" 
gmake  ncom  NCOM  USER=global 
cd  src/misc 

gmake  NCOM  USER=global 


For  compiling  simulations,  NCOM  ARCH  is  set  to  the  appropriate  machine  type, 
NCOM  COMP  (the  compiler).  The  NCOMUSER  variable  refers  to  user-specific  compile 
settings  that  are  available  in  the  appropriate 

config/$(NCOM_ARCH).$(NCOM_COMP).$(NCOM_USER).mk  makefile  fragment. 
Settings  specific  for  compiling  global  NCOM  on  IBM  with  the  AIX  (default)  compiler  are 
in  config/ibm_sp.default.global.mk  (See  Table  2.5-1).  These  are  enabled  by  setting 
NCOM_USER=global  in  the  user  environment  or  on  the  make  command  line,  as  shown 
above.  NOTE:  Do  not  use  libsetup,  as  it  is  not  needed.  The  file  ncom_setup_plib.F 
conflicts  with  strlen  in  the  netCDF  library  as  well.  See  Martin  et  ah,  (2008a)  for  a 
complete  discussion  of  required  and  optional  build  variables. 


Table  2.5-1:  Global  makefile  settings. 


Setting  Type 

Description 

Default  Setting 

Machine/Hardware 

IBM  SP  series 

Compiler  Set 

Native  (xlf/xlc) 

Communication 

Native  MPI 

CPPFLAGS 

CPP  flag  for  global  domain. 

+=-DGLOBAL DOMAIN 

INTLIB  SRC 

User  contributed  internal 

+=-cdf 

library  for  NCOM  SETUP 

+=  misc 

only. 

+=  modas 
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FCPATHS 

NetCDF  paths  for 
NCOMSETUP  only. 

+=  -I/site/netcdf64/include 

CCPATHS 

NetCDF  paths  for 

NCOM  SETUP  only. 

+=  -I/site/netcdf64/include 

LD  PATHS 

NetCDF  paths  for 

NCOM  SETUP  only. 

+=  -L/site/netcdf64/lib 

LDLIBS 

NetCDF  paths  for 

NCOM  SETUP  only. 

+=  -lnetcdf 

2.4.2  Accessing  the  GOFS  V2.6  Scripts 

The  GOFS  V2.6  is  executed  through  a  series  of  run  scripts  for  global  NCOM  and  its 
associated  programs.  These  are  located  in  the 

https://www7320.nrlssc.navv.mil/svn/repos/GQFS  repository.  Stepwise  instructions  for 
operating  the  system  can  be  found  in  Section  3.3. 

•  glb8_3b/  subdirectory-  Contains  the  daily  scripts  needed  to  run  the  global  model. 

•  scripts/  subdirectory-  Contains  the  post-processing  routines  and  a  link  to  netCDF 
versions  of  global  domain  grid  files  found  in  glb8_2a/nc. 

•  NCODA  directory-  Contains  scripts  required  to  run  the  global  NCODA  pre¬ 
processing. 

•  modas/syn/glb8_v3b  directory-  Contains  scripts  required  to  run  the  MOD  AS  pre¬ 
processing.  This,  in  turn,  generates  input  synthetic  files  in  a  separate  parallel  pre- 
process. 

•  PIPS  directory-  Contains  the  following: 

1.  PIPS  code  found  in  rundir.pips.v3.1,  bid,  and  source  (see  Posey  et  ah, 
2008a). 

2.  PIPS  domain  grid  files,  found  in  ncdirmaster  (see  Posey  et  ah,  2008b). 

3.  NOGAPS  and  NCOM  input  pre-processing,  found  in  data_in. 

4.  PIPS3  directory  containing  the  scripts  that  send  data  between  the  models. 
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3.0  Operating  Guidelines 

The  following  operational  guidelines  are  solely  for  instructions  unique  to  the  operation  of 
GOFS  V2.6.  The  user  should  refer  to  the  NCOM  4.0  User’s  Manual  (Martin  et  al.,  2008a) 
for  all  other  stepwise  directions  for  running  this  model. 

3.1  Initialization  and  Execution 

The  GOFS  V2.6  consists  of  several  UNIX  C  shell  scripts,  with  each  script  initializing  the 
next.  The  scripts  begin  by  creating  input  file  fonnats  required  by  global  NCOM  4.0  and 
ending  with  regional  extractions  of  the  outputs.  All  scripts  in  the  pre-processing,  model 
run,  and  post-processing  phases  of  the  daily  system  use  the  file  NCOM.env  to  set  most  of 
the  needed  environmental  variables. 

Three  environmental  variables  are  commonly  used  throughout  the  scripts.  The  starting 
date,  idtgl start,  is  set  via  the  NCOM.env  file.  It  is  the  beginning  of  the  hindcast,  generally 
set  three  days  prior  to  the  model  analysis.  The  analysis  date,  idtgl  analysis,  is  usually 
today’s  date.  The  forecast  date,  idtglend,  is  typically  set  to  four  days,  or  96  hours,  after 
the  analysis  date. 

3.1.1  Set  Macro  Values 

Set  MACRO  values  in  the  file  ncom_4.0/include/MACROS.h.  Macros  are  defined  in  Table 
3.1-1. 

Table  3.1-1:  User-defined  macros  of  MACROS,  h. 


Parameter 

Description 

MXPROC 

Maximum  number  of  processors  (<=  MX1PRC**2;  default  = 

256). 

MX  1  PRC 

Maximum  number  of  processors  in  either  direction  (x  or  y;  default 
=  16). 

MN1PRC 

Minimum  number  of  processors  in  either  direction  (x  or  y;  default 
=  2). 

NMXA 

Maximum  whole  array  dimension  in  either  direction  (x  or  y; 
default  =  2048). 

LMX 

Maximum  vertical  array  dimension  (max  number  of  layers  +  1 ; 
default  =  61). 

ARCTIC 

Used  for  a  global  domain  that  includes  the  Arctic  Ocean. 

GLOBAL 

Implements  code  for  running  in  a  global  operational  environment. 

GLOBALDOMAIN 

Sets  the  GLOBAL  macro  and  controls  compiling  with  global 
domain  array  settings. 

MYL2P5 

Implements  code  for  running  Mellor-Yamada  Level  2.5  mixing. 

COAMPS 

Implements  code  for  running  in  a  Coupled  Ocean  Atmosphere 
Mesoscale  Prediction  System  (COAMPS)  environment. 
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Parameter 

Description 

SYM4 

Provides  check  for  4-fold  symmetry  in  domain.  It  is  used  for 
testing  only. 

SYM8 

Provides  check  for  8-fold  symmetry  in  domain.  It  is  used  for 
testing  only. 

3.1.2  Set  Maximum  Dimensions 

Maximum  allowed  dimensions  are  set  in  the  file  ncom_4.0/include/PARAM.h .  These  will 
be  2048  xl280.  The  PARAM.h  variables  are  used  to  dimension  some  scratch  arrays  in  the 
model  code.  The  only  variable  that  changes  for  GOFS  usage  is: 

nrivmx-  maximum  allowed  number  of  (horizontal)  river  inflow  points,  set  to  2000. 

Note:  See  file  ncom_4.0/doc/READMEs/README.include  for  more  discussion. 

3.1.3  Updating  the  Rivers  File 

The  global  rivers  database  is  maintained  in  the  Subversion  repository  at 
https://www7320.nrlssc.navv.mil/svn/repos/RIVERS.  This  database  is  contained  in  the 
rivers.dat  text  file.  Its  README  file  explains  how  the  database  was  built  and  contains  a 
list  of  edits  made,  such  as  river  additions  and  corrections  to  mouth  locations.  The  file 
README.read.rivers.dat  gives  instructions  on  Fortran  direct  reads  of  the  text  file.  The 
README. make. modeiinput  contains  the  run  command 

ncom_setup_rivers.exe  rivers.dat  sstscl_gdem3vs . A 
sstscl_gdem3vs . B  orivs_l.D  ohgrd_l.A  ovgrd_l . D  odimens.D, 

which  takes  the  rivers.dat  flow  levels,  inputs  an  SST  and  sea  surface  salinity  (SSS) 
climatology  from  GDEM,  and  outputs  the  orivs  l.D  file. 

3.2  Setting  up  a  GOFS  V2.6  Simulation 

Global  NCOM  (ncoml)  runs  are  usually  only  changed  by  copying  an  entire  global 
directory  and  changing  the  OP  ARM  file  or  some  other  input.  Preprocessing  is  conducted  in 
the  top  level  NCOM  directory,  /u/home/ooc/models/ncoml/$runname.  To  start  the 
preprocessing  sequence,  type  csh  dailyncom.com  or  csh  dailyncom.  com  (date)  to 
redo  a  processing  sequence.  These  scripts  run  ncom_prep.com  with  appropriate  arguments. 
The  script  ncom_prep.com  gets  the  SST  and  SSH  data  from  mass  storage  as  well  as  other 
necessary  files.  It  then  starts  preparing  synthetics  using  syn_prep_poe.com,  which  queues 
one  dosyn.com  for  each  date  (all  running  in  parallel).  The  script  ncom_prep.com  grabs 
NOGAPS  atmospheric  forcing  fields  and  starts  their  preparation  using  atmstartprep.com, 
which,  in  turn,  queues  one  master_prep.com  for  each  date  (all  running  in  parallel).  Once 
synthetics  are  prepared,  ncom_prep.com  begins  preparation  of  T/S  assimilation  data  using 
tsstartprep.com.  The  script  tsstartprep.com  queues  one  master_prep.com,  which  calls 
ncom_sstsss_setup.com  and  ncom_ts_setup.com.  Once  all  preparations  have  finished, 
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ncom_prep.com  copies  data  to  operational  NAVOCEANO  DSRC  compute  platfonn  and 
mass  storage  and  queues  the  model  run  on  the  IBM  SP4,  at 
lu/home/ooc/models/ncoml/$runname/ startrun.com.  The  model  is  then  run  on  HABU  (if  the 
preparation  worked  correctly,  the  model  should  be  automatically  queued  and  no  human 
intervention  is  required). 

The  script  startrun.com  creates  a  run  script  for  the  model  named  ncom_$(runname)  _ 
$(idtglanalysis)).com,  which  is  based  on  master_script.com  and  master.awk.  The  model 
setup  is  controlled  by  parameters  set  in  OPARM_l_initial.D  or  OPARM_l_restart.D.  Once 
the  model  has  finished  its  run,  the  output  is  copied  to  mass  storage.  Model  post-processing  is 
conducted  on  the  IBM  SP4,  which  includes  copying  data  to  mass  storage,  making  2D  and  3D 
netCDF  files,  2D  RGB  files,  and  computing  transports.  The  interfacing  and  operational 
environment  for  the  global  NCOM  nowcast/forecast  system,  which  demonstrates  the 
relationship  between  the  components  of  the  system  and  associated  files,  is  illustrated  in 
Section  4.0. 

3.3  Executing  Pre-processing  Scripts 

•  The  dailyncom.com  script  is  initialized  via  a  crontab  that  calls 

ncom_prep.com. 

•  The  script  ncom_prep.com  is  the  longest  running  component  of  the 
system.  It  launches  jobs  on  the  operational  NAVOCEANO  DSRC 
compute  platfonn  to  create  surface  forcing  fields  from  NOGAPS  products, 
jobs  to  create  the  blended  synthetics,  and  resulting  assimilative  data  inputs. 
Specifically,  ncom_prep.com  calls  syn_prep.com,  ncoda_syn_prep.com, 
atmstartprep.com,  and  tsstartprep.com  and  then  waits  for  up  to  16 
hours,  testing  every  10  minutes  for  the  files  needed  to  place  the  model 
script  in  the  operational  queues.  Once  these  files  are  found,  startrun.com 
is  called,  generating  the  specific  script  needed  for  the  current  day’s  model 
run.  This  is  done  by  incorporating  master_script.com  via  master.awk. 
Once  the  model  run  enters  the  queue,  ncom_prep.com  is  complete. 

•  The  atmstartprep.com  script  takes  in  buildgrids_winds.com,  which 
reads  the  NOGAPS  file  formats  as  transferred  to  NAVO.  The  script  calls 
ncom_atm_prep_uvhtms.5.pf.exe  which  runs  on  one  processor  to  create 
surface  forcing  in  the  osflx  file  form  that  is  read  by  NCOM  4.0. 

•  The  script  syn_prep.com  builds  a  script  that  runs  dosyn_poe.com,  which 
incorporates  dosyn.com  to  run  one  job  per  day  of  the  model  run  (plus  an 
additional  start  -1  and  end  +1  day)  and  creates  MOD  AS  synthetics  for 
each  day  of  the  model  run.  The  resulting  2D  SSS  and  SST  and  3D 
synthetic  potential  T  and  S  files  are  output  in  netCDF  file  format. 

•  The  script  ncoda_syn_prep.com  generates  and  submits  a  date-specific 
version  of  ncoda_prep.com,  which  runs  transfer  input  data.s  and 
loop_analyses.s.  The  former  retrieves  the  needed  NAVO  OCNQC  profile 
data  and  MODAS  synthetic  T  and  S  files  that  will  comprise  the  NCODA 
first  guess.  The  latter  builds  and  submits  ncoda_analysis.com  for  each 
hindcast  date.  In  the  operational  queue,  these  multiple  NCODA  analyses 
run  concurrently.  At  the  end  of  each  NCODA  hindcast  analysis, 
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ncoda_post.com  first  runs  synthetics_post.s,  which  updates  the  first  guess 
field  with  the  analyzed  increments,  then  runs  transfer_output_data.s. 
Output  includes  netCDF  files  of  the  T  and  S  NCODA  analyses  as  well  as 
netCDF  and  binary  files  of  SST  and  SSS  that  have  been  extracted  from  the 
3D  T  and  S  files. 

•  The  script  tsstartprep.com  sources  ncom_sstsss_setup_source.com  and 
ncom_tsnc_setup_source.com,  which  run  ncom_sstsss.exe  and 
ncom_ts.exe,  respectively.  Each  runs  on  one  processor  and  reads  in  binary 
SST  and  SSS  files  or  netCDF  synthetic  T  and  S  files  and  creates  surface  or 
3D  files  in  the  osstf  and  otsf  file  forms  read  by  NCOM  4.0. 

3.4  Executing  Model  Run  Scripts 

•  Master_script.com  is  used  as  a  template  for  a  specific  script  submitted  to 
run  NCOM  4.0  every  day.  Startrun.com  creates  the  daily  script.  The 
model  executable,  ncom.exe,  runs  on  256  processors. 

•  The  model  script  calls  fixname.com  to  rename  the  model  outputs  into 
hindcast  and  forecast  specific  filenames.  It  calls  postproc_script.com  to 
begin  the  post-processing,  as  well  as  transfer_output_script.com  and 
transfer_restart_script.com. 

•  With  the  exception  of  transfer_output_script.com  and 
transfer_restart_script.com,  which  run  on  designated  nodes  to  send  data 
to  mass  storage,  the  256  processor  reservation  left  over  from  the  model  run 
is  retained  to  parallelize  post-processing  tasks. 

3.5  Post-processing  Scripts 

•  The  postproc_script.com  script  runs  out2ncplus_sf_script.com  and 
out2ncplus_3d_script.com,  creating  separate  scripts  for  each  model  day 
for  the  surface  and  3D  fields,  respectively.  Each  of  these  calls  the  script 
ncom_out2ncplus_all.com  to  run  ncom_out2ncplus.exe,  which  perfonns 
all  of  the  refonnatting  to  generate  netCDF  and  transport  files  from  the 
model’s  binary  outputs. 

•  The  out2ncplus  scripts  launch  the  transfer  of  all  netCDF  and  transport 
files  to  mass  storage.  They  incorporate  the  following  three  modules  into 
jobs  that  run  in  the  transfer  queue:  transfer_nc_3d.module, 
transferncsf.module,  and  transfer  transportmodule. 

•  The  out2ncplus  scripts  launch  the  standard  regional  extraction  routines 
using  regional_tasks.com,  which  reads  a  list  of  regions  from 
regional_tasks.lis.  Each  regional  extraction  routine  is  very  specific  and 
must  be  hand-edited  to  specify  the  coordinates  of  the  sub-region  and  the 
type  of  field  to  be  extracted. 

3.6  Executing  Regional  Post-processing  Scripts-  NCOM  coupling  with  PIPS  3.0 

•  After  NCOM  runs  each  day,  it  calls  the  regional  post-process 
script  launch_pips.com,  which  runs  ncom2pips.com  for  that  day. 
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The  ncom2pips.com  script  uses  MODAS  regridding  routines  to  regrid  the 
NCOM  surface  temperature  and  velocities  onto  the  PIPS  grid  in  netCDF 
fonnat.  PIPS  then  extracts  the  data  from  the  netCDF  files  into  a  text  file 
and  runs  average_file_realtime.x  to  make  a  daily  mean  for  input. 

•  After  PIPS  3.0  has  run,  launch_ncom.com  is  called.  This  runs 
ncom2pips.com,  which,  in  turn,  starts  the  parallel  process 
regrid_pips_poe.com  of  serial  jobs.  Following  these  script  runs, 
regrid_pips.com  will  regrid  the  PIPS  output  every  three  hours  onto  the 
NCOM  grid,  including  the  ice  concentration,  heat  flux,  and  ice-ocean 
stresses.  Sea  surface  temperature  files  are  only  regridded  at  the  00  hour. 
The  fili4.com  routine  masks  noise  at  the  land-sea  boundaries,  and  the 
landmask.com  script  places  the  NCOM  landmask  onto  the  newly  gridded 
fields. 

•  Ice-ocean  stresses,  heat  fluxes,  and  ice  concentrations  are  brought 
into  ncom_4.0/bin/sigz.global/ncom_nc2atmice.exe,  thus  creating  an 
atmice.A  file.  PIPS  3.0  is  run  for  96  hours  and  files  are  persisted  for  an 
additional  24  hours.  The  atmice.A  file  is  saved  for  the  following  day. 

•  The  executable 

ncom_4.0/bin/sigz.global/ncom_atmuvhtms_icemask3.01.exe  is  run  the 

next  day,  after  the  NOGAPS  forcing  OSFLX_l.A  file  is  made.  This  uses 
ice  concentration  to  determine  where  ice  is  present  (at  a  concentration  of 
1%  or  higher)  and  replaces  wind  stresses  with  ice  ocean  stresses  and  heat 
fluxes  over  the  NCOM  bulk-formulae  heat  fluxes. 

•  The  SST  outputs  are  blended  into  the  MODAS  2D  synthetics  by  using  ice 
concentration  to  determine  where  ice  is  present.  The  ice  concentration  file, 
aice,  is  used  to  assess  three  types  of  areas:  those  with  significant  ice,  those 
near  ice  areas,  and  those  in  open  water.  A  minima  of  ice  areas  with  a 
value  of  at  least  0.0001  creates  a  lesser  ice  mask  and  is  used  to  make  a 
mask  of  l’s  and  0’s.  A  creep  fill  is  used  to  expand  the  mask  to  areas  near 
ice.  In  near-ice  areas  and  in  regions  with  high  ice  concentration  l’s  are 
used  and  for  open  water  0’s  are  used.  For  in-between  areas,  a  blend  zone 
filled  with  special  values  has  been  created. 

•  An  ice  mask  ( blendmask )  of  l’s  and  0’s  is  generated  as  well  as  an  inverse 
ice  mask  ( blendmaski )  of  0’s  and  l's.  The  blendmaski  will  be  multiplied  by 
the  MODAS  SST  output  the  following  day.  The  blendmask  is  multiplied 
by  the  PIPS  SST  netCDF  output. 

•  By  running  grdmath.com,  the  PIPS  and  MODAS  blended  files,  with  their 
inverse  masks,  are  added  together  in  the  NCOM  synthetic 
pre-processing  for  the  following  day.  Persisted  files  are  used  to  make 
up  for  the  last  record. 
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4.0  GLOBAL  OCEAN  FORECAST  SYSTEM  V2.6  FLOWCHARTS 

4.1  Operational  GOFS  V2.6  Flowchart 


Operational  Global  NCOM 


glb_2a 

I  ohgrd_l.[AB], 
ovgrdl.D, 
odimens.D, 
oinit_l.[AB],  I 
otscl_l.[AB],  / 
otsza_l.[AB],  / 
orivs  l.D  /_ 


NCOM.env 


Cron  job  which  starts  the  whole 
system  on  operational  platform  \ 

Run  dailyncom.com  at  prompt  (from  CRON)  to 
launch  ncom_prep.com  (also  on  command  line) 
.in  /u/home/ooc/models/ncoml/$runname  I 


*■/  Current  day’s 
/ncom_prep_$yyyymmdd.  log 
(on/scr/ooc/data/ncoml/  / 
$runname/log)  / 


Make  NOGAPS  forcing 
input  files  for  model 
atmstartprep.com 

startdate  enddate  analysisdate 


prep_atm_$analysisdate.com 

runs  in  batch  queue 


master_prep.com 

atmtype=l 


I 


■ 


buildgrids_winds.com 

makes  binary  version 
of  NOGAPS  files. 


atmice.A  goes  into 
ncom_4.0/bin/sigz.global/ncom 
atmuvhtms  icemask3.01.exe 


/osflx_$idoatp_$idotau_$idosft_$idosi's_$startdate_$analysisdate_ihrsCl_icemask3ed.A 
/  is  copied  into  the  commonly  accepted  osflx.A  filename  / 

/  osflx  Sidoatp  Sidotau  Sidosft  Sidosfs  Sstartdate  Sanalvsisdate  ihrsf  l  .Ay/ 

/  The  usual  .B  file  remains  unchanged:  / 

/osflx_$idoatp_$idotau_$idosft_$idosfs_$startdate_$analysisdate_ihrsf_l.B.  // 


ncom_atm_prep_uvhtms_$startdate_$analysisdate.log 

patm_$analysisdate.log 

(on  /scr/ooc/data/ncoml/log/atm) 


Make  intermediate  synthetics  files 


syn_prep.c°m  submits  one  job  in  batch  queue  -  two  nodes. 
dosyn_poe.com  submits  two  sets  of  days  (up  to  eight  days  each)  which  runs  a 
separate  dosyn.com  job  for  each  model  day  plus  one  day  at  the  beginning  and  end. 
All  date-specific  .com  files  are  located  on  /scr/ooc/data/ncoml/$runname/log/syn. 
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ptsynn_yyyymnidd.nc  and  ssynnyyyymmdd.nc 

as  well  as  sstn_yyyymmdd.bin  and 
sssn_yyyymmdd.bin  for  each  model  day  plus  one 
at  the  beginning  and  one  at  the  end.  Copy  inputs 
to  NEWTON  after  tsstartprep  (all  located  in 
/  scr/ ooc/ data/ ncom  1  /  modas/ syn/work/glb  8_v3b) . 
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ncom  4.0 


master_script.com 


Make  model  script 
startrun.com  creates 
ncom_$runname_$analysisdate.com. 
startrun.com  checks  for  all  inputs: 
outsf/otsf/osstf  and  the  restart  files 
$runname_rstl  yyyymmdd  00000000.A 
and 

$runname_rstl  yyyymmdd  00000000.B. 

It  builds  the  script  and  submits  the  NCOM 
job  to  the  internal  queue  on  16  nodes. 


glb_2a 

ohgrd_l.[AB], 

ovgrdl.D, 

odimens.D, 

oinit_l.[AB], 

otscl_l.[AB], 

otsza_l.[AB], 

orivs  l.D 


The  restart  parameter  file 

OPARM_l_restart.D,  which  is  stored  permanently  in 
/u/home/ooc/models/ncoml/$runname  is  copied  to 
OP  ARM  l.D  (new  format  for  NCOM  version  4.0). 
OPARM_l.D  tells  the  model  how  frequently  to  write  outputs 
and  specifies  the  types  of  numerics  to  do  and  the  types  of  inputs 
to  use.  / 


t 
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Run  model 

ncom_$runname_$analysisdate.com  runs  in  the  batch  queue  on  the 
operational  platform  on  256  processors/16  stays. 


'Binary  files: 

out3d_l_yyyymmdd  00000000.A, 
out3d_l_yyyymmdd  00000000.B, 
outsflyyyymmddOOOOOOOO.A,  and 
outsflyyyymmddOOOOOOOO.B 

files.  (The  _1_  stands  for  nest  1) 


The  restart  files  retain  their 
naming  convention: 
$runname_rst_l_yyyymmdd_h  t 
hhhhhhh.i  AB 


fixname.com 


I  Saved  on  /scr  for  the  next 
\  day’s  model  run. 


^out3d_$runname_2f_yyyymmddhh.[AB]  and 
outsf  _$runname_yyyymmddhh.[AB]  for  hindcasts. 
out3d_$runname_yyyymmdd00_trrrh.[AB]  and 
outsf_$runname_yyyymmddOO_trrrh.[AB],  where  rrr 
is  the  3 -digit  difference  time  starting  from  the  analysis 
(000)  to  the  last  forecast  (072). 


postproc_script.com  submits  two  jobs  in  batch  queue  (13  nodes  for  3D  and  seven 
nodes  for  surface).  It  runs  ncom_out2ncplus_all.com. 

out2ncplus_sf_script.com  submits  two  sets  of  days  (up  to  eight  days  each)  that  run  a 
separate  out2nc_sf_yyyymmdd.com  for  hindcasts,  as  well  as 

out2nc_sf_yyyymmdd00_trrrh.com. 

out2ncplus_3d_script.com  submits  two  sets  of  days  (up  to  eight  days  each)  that  run 
a  separate  out2nc_3d_yyyymmdd.com  for  hindcasts  and  also  run 
out2nc_3d_yyyymmdd00_trrrh.com  (this  also  launches  transfers,  regional 
processing,  and  boundary  condition  processing  from  node  0). 

All  date-specific  .com  files  are  located  on  /scr/ooc/data/ncoml/$mnname/log/nc. 
Transfer  .corns  and  logs  are  located  in 
/scr/ooc/data/ncoml/$runname/log/nc/transfers. 
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'SSH,  VBH,  [STUV]  3D  netCDF  files  wi 
filename 

fff_$runname_yyyymniddOO  trrrh.nc 

where  fff  'vs,  the  field  name  and  rrr  is  the 
3 -digit  difference  time  from  the 
analysis  (000). 

fff_$runname_yyyymniddhh.nc  is 

the  filename  for  hindcasts. 


i|th  /  I  Transport  ASCII  files  with  filename 

'transport_$runname_yyyymmdd00_trrrh 
.dat,  wherc  ///  is  the  field  name  and  rrr  is  th^ 
3 -digit  difference  time  from  the  analysis 
(000). 

transportSrunnameyyyymmddhh.n^i 

is  for  hindcasts. 


SS[HST]  RGB  files  with  filename 

$fff  Srunname  yyyymmddOO  trrrh.rgb, 

where  fff\s  the  field  name  and  rrr  is  the  3- 
digit  difference  time  from  the  analysis 
(000). 

fff_$runname_yyyymniddhh.rgb  is  the/ 
filename  for  hindcasts. 


netCDF  files  remain  on  /scr  for  regional  processing. 


t 
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transfer_nc_sf.module  transfer_transport.modul  transfer_nc_3d. module 


Transfer  netCDF  and  transport  files  to  mass  storage  for  archival  and  post- 
processing  access  (including  NRL-SSC  and  NRL-MRY): 
trnsfr_out2ncplus_|sf]  |3d]_$runname_yyyymmdd_all.com  launches 
transfer_out2ncplus_trns_$runname_yyymmdd_yyyymmdd.com, 
transfer_out2ncplus_3d_$runname_yyymmdd_yyyymmdd.com,  and 
transfer_out2ncplus_sf_$runname_yyymmdd_yyyymmdd.com  for  each  model  day. 
trnsfr_out2ncplus_|sf][3d]_$runname_yyyymmdd_all.com  is  run  from  the  transfer  . 
queue  but  may  also  be  run  from  the  command  line. 


Transfer  binary  output  files  to  mass  storage  for  archival  and  post^^^^ 
processing  access  (including  NRL-SSC  and  NRL-MRY): 
trnsfr_all_yyyymmdd.com  launches  trnsfr_arch_runname_yyymmdd.com, 
which  launches  a  trnsfr_arch_runname_yyyymmdd_yyyymmdd.com  for 
each  model  day.  Trnsfr_rst_runname_yyyymmdd.com  launches  a 
trnsfr_rst_runname_yyyymmdd_yyyymmdd.com  for  each  model  day. 
Trnsfr_all_yyyymmdd.com  is  run  from  the  transfer  queue  but 
can  also  be  run  from  the  command  line. 
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5.0  TROUBLESHOOTING  GOFS  V2.6 


Problem 

Solution 

Model  has  not  queued  by  three 
hours  after  initial  sourcing  of 

dailyncom.com. 

Look  in  queues  for  any  other  OOC  jobs  with  names 
containing  atm,  ts,  or  syn.  If  none  are  in  the  queue,  backtrack 
to  /scr/ooc/data/ncoml/$runname/input  to  look  for  inputs. 

Osflx  files  do  not  exist  in 

/scr/ooc/data/ncoml/$runname 

/input. 

Go  to  /scr/ooc/data/ncoml/$runname/log/atm.  A 
resubmission  of  prep_atm_yyyymmdd.com  will  probably 
catch  any  missing  inputs  due  to  late  NOGAPS  transfer. 

Otsf  files  do  not  exist  in 

/scr/ooc/data/ncoml/$runname 

/input. 

Go  to  /scr/ooc/data/ncoml/$runname/log/syn.  If  one  of  the 
log  files  for  a  particular  day  is  much  smaller  than  the  others, 
resubmit  that  one  day  by  going  to 
/home/ooc/models/ncoml/modas/syn/regs/glb8_v3b  and 
manuallytypingqdosyn.com  yyyymmdd.  If  all  days 
have  problems  go  back  to 
/home/ooc/models/ncoml/$runname  and  type 
syn  prep  poe.com  -idtglstart  yyyymmdd  - 
idtglend  yyyymmdd  -idtglanalysis  yyyymmdd. 

Model  is  still  not  in  queue.  It 
is  prior  to  the  reservation  time 
and  all  inputs  exist  and  are 
standard  size. 

Check  the  log  file  in  /scr/ooc/data/ncoml/$runname/log 
called  ncom_prep_yyyymmdd.log.  Do  a  tail,  and  if  the  end 
is  still  within  the  loop,  look  for  the  full  size  otsf  file,  wait  ten 
minutes,  and  see  if  it  queues. 

Model  did  not  queue  before 
reservation  time. 

Edit 

/u/home/ooc/models/ncom l/$runname/ncom  $runname_yyyy 
mmdd.com  by  taking  out  the  startdate  line  at  top  and 
changing  from  internal  to  batch  queue.  The  model  has  missed 
its  reservation  but  can  wait  for  an  opening  in  the  queues  to 
run  regularly. 

Post-processing  did  not 
complete. 

Go  to  /scr/ooc/data/ncoml/$runname/log/nc  for  log  files.  If  a 
rerun  is  needed,  go  to  /u/home/ooc/models/ncoml/$runname/ 

and  run  csh  postproc  script.com  -idtglstart 
yyyymmdd  -idtglend  yyyymmdd 

idtglanalysis  yyyymmdd. 

Files  did  not  transfer. 

Transfers  can  also  be  run  interactively  or  resubmitted  to  the 
transfer  queue.  Go  to 

/scr/ooc/data/ncoml/$runname/log/transfers 
for  model  output  and  to 

/scr/ooc/data/ncoml/$runname/log/nc/transfers  for  converted 
netCDF  outputs.  Look  for  .com  files  with  all  and  the  analysis 
date  in  the  filenames.  Resubmit  the  *all*  .com  files  with 
all  submit  to  the  transfer  queue  or  with  the  csh  filename 
on  the  command  line. 
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A  regional  extraction  did  not 
run  in  the  regular  pre¬ 
processing  or  it  needs  to  be 
rerun  or  run  for  another  date. 

Go  to 

/u/home/ooc/models/ncoml/$runname/regs/${regionname} 
Most  regional  extractions  are  set  up  with  a  README  file, 
where  a  local  script  is  run  with  an  input  of  an  analysis  date. 

Ex:  ncom2points.com -idtglanalysis  yyyymmdd 

CICE  did  not  run. 

The  /scr/ooc/data/ncoml/pips/pipsfrcst/atmice.A  file 
should  exist  from  the  previous  day.  If  present,  NCOM  pre¬ 
processing  will  use  it.  The  PIPS  SST  fields  will  be  persisted 
in  the  MODAS  pre-processing. 

NCOM  gives  error  at  start  of 
initial  check  stating  T  is  below 
allowed  value 

Run  /u/home/ooc/models/ncoml/ncom_4.0/bin/sigz. global/ 
ncom  fixrst.exe  on  first  hindcast  day’s  restart  file.  Use  restart 
file  name,  and  (2048,  1280,  40)  values  as  inputs. 
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7.0  NOTES 

7.1  Acronyms  and  Abbreviations 


Acronym 

Description 

ASCII 

American  Standard  Code  for  Infonnation  Interchange 

CICE 

Los  Alamos  Sea  Ice  Model 

COAMPS 

Coupled  Ocean  Atmosphere  Mesoscale  Prediction  System 

cpp 

C  compiler 

DoD 

Department  of  Defense 

DTG 

Date  Time  Group 

ECMWF 

European  Center  for  Medium-range  Weather  Forecast 

GB 

GigaByte 

GDEM 

Global  Digital  Elevation  Map 

GOFS 

Global  Ocean  Forecast  System 

HPCMP 

High  Performance  Computing  Modernization  Program 

IEEE 

Institute  of  Electrical  and  Electronic  Engineers 

PO 

Input/Output 

IP 

Internet  Protocol 

MB 

MegaByte 

MLD 

Mixed  Layer  Depth 

MODAS 

Modular  Ocean  Data  Assimilation  System 

MPI 

Message  Passing  Interface 

DSRC 

DoD  Supercomputing  Resource  Center 

NCODA 

Navy  Coupled  Ocean  Data  Assimilation 

NCOM 

Navy  Coastal  Ocean  Model 

netCDF 

Network  Common  Data  Form 

NLOM 

Navy  Layered  Ocean  Model 

NOGAPS 

Navy  Operational  Global  Atmospheric  Prediction 

NRL-SSC 

Naval  Research  Laboratory,  Stennis  Space  Center 

NRL-MRY 

Naval  Research  Laboratory,  Monterey 

OCNQC 

Quality  Controlled  Ocean  Data 

OOC 

Optimizing  Oberon-2  Compiler 

PIPS 

Polar  Ice  Prediction  System 

RCP 

Run  Control  Parameter 

S 

Salinity 

SDD 

Software  Design  Description 

SSC 

Stennis  Space  Center 

SSH 

Sea  Surface  Height 

SSS 

Sea  Surface  Salinity 
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Acronym 

Description 

SST 

Sea  Surface  Temperature 

SVN 

Subversion 

T 

Temperature 
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